In the computer systems architecture world, cloud computing has recently received some attention. Although there are many competing definitions for “cloud computing,” it generally involves (1) the delivery of computing as a service rather than a product, and (2) providing shared processing and/or storage resources, software, information, etc., to computers and other devices as an oftentimes metered service over a network (typically the Internet). In a cloud computing environment, end users do not necessarily need to know the physical location and configuration of the system that delivers the services. Applications typically are delivered to end-users as the service, enabling transparent access to the cloud-based resources.
An interesting trend within cloud computing relates to the emergence of “hybrid” cloud solutions that span multiple (cloud) environments that were historically isolated from one another. In a typical such scenario, a cloud application comprises parts that must remain within enterprise IT boundaries (e.g., a private cloud) while other parts are deployed into a third-party hosted cloud infrastructure. An example of parts of a cloud application that must remain within enterprise confines may include, for example, application components that manipulate and utilize enterprise sensitive data. By contrast, other parts of the application such as end-user oriented parts or parts that need to integrate with partner solutions, etc., may be deployed into third-party cloud infrastructure (e.g., for the benefits offered by hosted cloud environments such as, for example, elastic scaling, efficient resource utilization, capital expenditure cost reduction, etc.).
Cloud technology is still developing and indeed is still be defined in some respects, and further refinements are still being sought after in both the theoretical and practical worlds. The emergence of hybrid cloud solutions also presents several practical challenges. For instance, enterprise class and other vendors are concerned with security, privacy, availability of cloud provider infrastructure, etc.—as well as the sometime apparent lack thereof. As a result, vendors oftentimes would like to keep enterprise-sensitive data and/or related logic within the enterprise controlled private-cloud environments.
Additionally, even for components of the cloud application that are deemed to be safely deployable into public cloud environments, it sometimes is desirable to deploy additional instances of those components dynamically for load-balancing, performance, fail-over, and/or other purposes. These additional instances may be deployed into the same cloud-provider as the original instance within the same or different availability zone(s), or even into an entirely different cloud provider, e.g., when the original cloud provider experiences an outage.
Thus, it will be appreciated that there is a need in the art for improved cloud computing techniques that take into account these and/or other concerns, particularly where hybrid environments are concerned.
One aspect of certain example embodiments relates to a mechanism that enables the description of cloud applications with multiple constituent parts that can be deployed into heterogeneous cloud environments (e.g., hybrid cloud solutions). In certain example embodiments, these techniques help facilitate the above-described and/or other scenarios that often arise in cloud computing environments.
Cloud application descriptions are just emerging as a concept, and it is believed that the current state of the art describes cloud applications as deployable into a single cloud provider environment (e.g., as a cloud appliance) and does not address cloud application deployment over heterogeneous and distributed cloud environments that span both private and public cloud environments, from different vendors. Additionally, it is believed that current cloud application descriptions do not address load-balancing and fail-over deployment, or the ability to designate certain parts of the cloud application to be constrained for deployment into discrete, defined zones (e.g., enterprise private cloud environments only). Indeed, it is believed that currently emerging proposals are limited to describing an application deployment into a single cloud provider environment, mostly defined by Cloud Providers, to facilitate deployment of applications into their own cloud infrastructure. Examples of such descriptions are Amazon EC2's AMI (Amazon Machine Image) and the OVF (Open Virtualization Format).
Thus, it will be appreciated that there is need to facilitate the description of cloud applications with constituent parts that are distributed over heterogeneous cloud environments including, for example, private, public, and community cloud infrastructures.
As will become apparent from the detailed description below, one aspect of certain example embodiments relates to techniques that facilitate the deployment description of distributed cloud applications that span private and public cloud environments, while also potentially enabling fail-over and load-balancing measures to be implemented.
Another aspect of certain example embodiments relates to techniques for identifying different cloud deployable units of a cloud application, properties on each describing the nature of the application, configuration and requirements on the cloud provider environments that these application units may be deployed into, and/or the like. In certain example implementations, the properties on each unit can also include attributes that specify criteria for deploying additional instances of the unit into cloud provider and fail-over deployment.
In certain example embodiments, a computer-implemented method for setting up a cloud application in a heterogeneous distributed cloud provider environment including multiple computer systems is provided. The computer systems are operated by different cloud providers. The cloud application is defined in terms of constituent nodes, with each said node representing a part thereof that is to be deployed into a single one of said computer systems that satisfies deployment requirements of that node. Properties identifying deployment requirements of, and application level instantiation logic for, each said node, are defined. For each said node, any (e.g., one or more) interfaces that are invokable by one or more other nodes are exposed. For each said node, any (e.g., one or more) interfaces that it will invoke on one or more other nodes are identified. Exposed interfaces and complementary invokable interfaces are matched with one another.
In certain example embodiments, there is provided a computer-implemented method for setting up an application in a cloud computing network environment in which different cloud providers operate respective computer processing systems.
A definition of the cloud application that includes a list of its constituent nodes is received, with each said node representing a part thereof that is to be deployed into a single one of said computer processing systems, and with the definition including lists of predefined deployment requirements of, and application level instantiation logic for, each said node, as well as matches between exposed and invokable interfaces of complementary ones of said nodes. The nodes are deployed to the computer processing systems in dependence on the definition of the cloud application, such that the nodes are able to operate on the computer processing systems to which they are deployed, given requirements of the nodes and capabilities of the computer processing systems, with the capabilities of the computer processing systems depending at least in part on the processors and infrastructure configurations thereof.
Non-transitory computer readable storage mediums tangibly storing instructions for performing the above-summarized and/or other methods also are provided by certain example embodiments, as well as corresponding computer programs.
Systems and or computer based apparatus may also be configured or adapted to implement the above-summarized and/or other methods provided in certain example embodiments.
For instance, in certain example embodiments, a cloud application design system for setting up a cloud application in a heterogeneous distributed cloud provider environment including multiple computer systems is provided. The computer systems are operated by different cloud providers. At least one processor is provided. A user interface operating under the control of the at least one processor is configured to receive input: (a) defining the cloud application in terms of constituent nodes, with each said node representing a part thereof that is to be deployed into a single one of said computer systems that satisfies deployment requirements of that node, (b) defining properties identifying deployment requirements of, and application level instantiation logic for, each said node, (c) indicating, for each said node, one or more interfaces that are to be exposed as invokable by one or more other nodes, (d) identifying, for each said node, one or more interfaces that it will invoke on one or more other nodes, and (e) indicative of how exposed interfaces are to be matched to complementary invokable interfaces. A first storage location (which may be non-transitory in certain example instances) is configured to store the input in a predefined format. A second storage location (which may be non-transitory in certain example instances) is configured to store artifacts used in supporting the application level instantiation logic of the nodes.
These features, aspects, advantages, and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.